REVIEW OF "BACKGROUNDER II" from PLU*PERFECT SYSTEMS

Rick Charnes
1165 Shotwell St.
San Francisco, CA
826-9448 or 821-4345

(c) Copyright 1987 by Rick Charnes and Morrow Owners Review

Date of submission: August 17, 1987
for October-November 1987 issue

Contents: 4800 words


In thinking about writing this review, I realized early on that I
 ¨
was going to need to wax a bit philosophical, because it is only ¨
 ¨
in that state of mind that one can begin to appreciate what this ¨
 ¨
program is all about. ¨


Backgrounder II is a "task-switching" utility for Z80 (CP/M- ¨
 ¨
compatible) computers. Fundamentally this means that a user can ¨
 ¨
"swap" back and forth between two running programs [BEGIN ¨
 ¨
BOLD]without leaving either of them.[END BOLD]  The first ¨
 ¨
application stays suspended while you go to the second, and when ¨
 ¨
you return it is there exactly how you left it. Switching back ¨
 ¨
and forth between the two is as easy as a single command or even ¨
 ¨
a single keystroke. With Backgrounder, for instance, there is no ¨
 ¨
longer any need to exit NewWord if you need to do some file ¨
 ¨
manipulations with NewSweep or get some information from DBase. ¨
 ¨
If you have a HELP file for a program you don't have to leave the ¨
 ¨
program to view it!  Or you can, if you have a screen driver, ¨
 ¨
transfer calculations between SuperCalc and the report you're ¨
 ¨
writing in NewWord. But before I give away all the applications, ¨
 ¨
let me muse a little bit as promised. ¨


I've been using Backgrounder II (or BGii as it's affectionately ¨
 ¨
called) for about 6 months now on my 20 meg Mini Winnie-equipped ¨
 ¨
MD3. It's interesting for me to think back to the days before I ¨
 ¨
added BGii to my personal computing system, because it makes me ¨
 ¨
realize how much I've since come to take for granted; it's always ¨
 ¨
hard to keep a "beginner's mind." I can easily remember, however, ¨
 ¨
the initial motivating factor for my interest in BGii. Sitting at ¨
 ¨
my desk is and always has been an "in/out" box hugely full of ¨
 ¨
papers. Through the course of any week as I work with my computer ¨
 ¨
and experiment with various new techniques and programs I am ¨
 ¨
constantly taking notes and writing things down:  questions to ¨
 ¨
ask others, ideas to try at a later date, etc. I very often have ¨
 ¨
questions or comments on ZCPR3 programs I am using and later ¨
 ¨
upload these to Z-Node BBS's in order to share these with others. ¨


I remember very distinctly one day being particularly puzzled by ¨
 ¨
one program I was working with and frantically writing down my ¨
 ¨
experiences with it on a piece of paper to be ultimately sent as ¨
 ¨
questions to its author. As I became more and more involved with ¨
 ¨
taking these notes it suddenly hit me: here I was using this ¨
 ¨
advanced and sophisticated piece of technology and yet I was ¨
 ¨
writing the results of it all on this piece of paper!  The ¨
 ¨
funniest thing is that I would always later transfer everything ¨
 ¨
from paper to computer disk; it was my first intimation of the ¨
 ¨
possibly of eliminating the middle man. ¨


Running BGii on your system gives you a curious sensation of ¨
 ¨
having two computers. It's a delightful feeling. Right now I'm ¨
 ¨
writing this in NewWord. Let's suppose that I temporarily forgot ¨
 ¨
some arcane technical point of BGii and remembered that someone ¨
 ¨
left a message about exactly that on a BBS halfway across the ¨
 ¨
country. Without even needing to ^KD to save my work I hit a ¨
 ¨
single key called the <SUSPEND> key and I'm immediately placed at ¨
 ¨
the BGii system prompt. Note that I can not yet access a CP/M or ¨
 ¨
ZCPR3 program as I have not yet issued the swap command. I am ¨
 ¨
now, however, placed in a position where I have access to the ¨
 ¨
second and additional major feature of BGii: THIRTY-SEVEN (37!) ¨
 ¨
memory-resident commands that are available without leaving an ¨
 ¨
application program. When I run the command that displays these ¨
 ¨
37 commands and scan through them I still feel somewhat ¨
 ¨
unbelieving that I have all this power within my 64k memory (and ¨
 ¨
I'm doing it with a full Z-System and 2k taken out for a hard ¨
 ¨
disk driver!), but it's true. Here's what displays on my screen ¨
 ¨
when I type "BG": ¨


.RR--!----!----!----!----!----!----!----!----!----!----!---------------------R
Cmds: low Foreground  d03:CP/M    label ¨

bg     calc   cls    cut    date   dir    echo   era    feed   find   forms
flip   go     get    help   jot    jump   keys   list   ndr    note   ocp
peek   poke   printr ren    reset  save   screen shift  spool  swap   time
type   user   whl    whlq
bghist bgerrh cp     e

.RR--!----!----!----!----!----!----!----!----!----!----!--------R

If you haven't guessed by now, in order to get the above display ¨
 ¨
printed in my text I didn't need to leave NewWord. BGii helped me ¨
 ¨
take a picture of itself. In any case I have access to all of the ¨
 ¨
above commands, and they are all memory-resident and therefore ¨
 ¨
load almost instantaneously. ¨


But this isn't what I wanted to do; I was going to do some ¨
 ¨
roaming of the electronic ether. I'm now at what BG calls the ¨
 ¨
"foreground prompt" which looks very much like an ordinary CP/M ¨
 ¨
or ZCPR3 prompt, and I type "SWAP;MEX". Here is where BG really ¨
 ¨
goes to work. There exists on my A0: drive a 102k file called ¨
 ¨
!!BG.SWP. [Again: just now I forgot its exact name and was able ¨
 ¨
to issue a "DIR A0:" command to display it without leaving my ¨
 ¨
text!]  This is the file that contains a [BEGIN BOLD]disk- ¨
 ¨
based[END BOLD] image of what the computer's [BEGIN ¨
 ¨
BOLD]memory[END BOLD] looks like when NewWord has loaded this ¨
 ¨
text. Everything that exists in memory is transferred over to ¨
 ¨
this disk file, which is called the swap file. When I later give ¨
 ¨
the <SUSPEND> command again to return to my text, the disk-based ¨
 ¨
swap file will empty itself out back into memory and the screen ¨
 ¨
and rewrite everything precisely how it appeared down to the ¨
 ¨
exact cursor location. ¨


After I issue "SWAP;MEX" I am then presented with a different ¨
 ¨
prompt (the drive letter is in lower case) that reminds me I am ¨
 ¨
in my "lower task," MEX. I am free to climb aboard my modem and ¨
 ¨
make that call to the BBS on which I can get the information I ¨
 ¨
need. After reading it and logging off the BBS, I don't have to ¨
 ¨
exit from MEX in order to return to NewWord. After all, I may ¨
 ¨
need to do it again; why waste time reloading programs?  I simply ¨
 ¨
hit my <SUSPEND> key again (default is "^^" which on my Qume 102a ¨
 ¨
terminal is a single key) and I'm taken to the background prompt ¨
 ¨
again. It takes a while to get used to the different prompts as ¨
 ¨
there are four of them -- upper task background and foreground ¨
 ¨
and lower task background and foreground -- but once you do they ¨
 ¨
are a great help in reminding you where you are. The upper task ¨
 ¨
prompts have the drive letter in upper case and with the lower ¨
 ¨
tasks it is in lower case, while the background prompt uses the ¨
 ¨
"}" instead of the normal foreground ">" as in ordinary CP/M. ¨


In any case, from the background prompt I simply issue the ¨
 ¨
command "SWAP" again and I'm taken back into NewWord, precisely ¨
 ¨
where I was when I left off. It's all quite amazing to see. I ¨
 ¨
should emphasize that there are at least two distinct components ¨
 ¨
to this BGii environment, the task-switching (or "context- ¨
 ¨
switching," as it's often called) and the memory-resident ¨
 ¨
background commands. While much has rightfully been made of the ¨
 ¨
former, the latter are also extremely impressive and their ¨
 ¨
variety and power are awesome. ¨


One application I just used: I wanted to have a printout of the ¨
 ¨
37 commands in order to write about them. Since I am using ¨
 ¨
NewWord and not WordStar I have no "print block" (^KP) command ¨
 ¨
which I could ordinarily use to print them out from my text ¨
 ¨
above. Solution: I had them on a disk file and simply hit my ¨
 ¨
<SUSPEND> key to get to the background prompt. I then used the ¨
 ¨
memory-resident LIST command to print them out and was back to my ¨
 ¨
text in a split-second. ¨


The resident CALC feature is extremely useful for those working ¨
 ¨
with figures. It provides addition, subtraction, multiplication ¨
 ¨
and division of decimal and hexadecimal numbers and three memory ¨
 ¨
storage registers. One of the nice touches here, and something it ¨
 ¨
incidentally has in common with WordStar 4.0, is the ability to ¨
 ¨
insert the result of an equation into any text you're working on, ¨
 ¨
via a two-key sequence. ¨


This ability to take output from one program and translate it ¨
 ¨
into input to another is something I find extremely useful with ¨
 ¨
BGii. For instance, one feature I really find very nifty -- ¨
 ¨
especially as until now it's been one of the things I've envied ¨
 ¨
about the MS-DOS world -- is the ability to strike a two-key ¨
 ¨
sequence and watch today's date appear on screen. This requires ¨
 ¨
running DateStamper along with it. These two programs go together ¨
 ¨
like hand in glove. Writing a letter to a friend but can't ¨
 ¨
remember the date to put in the header?  Just strike "\d" and ¨
 ¨
you've got the date. When we all get our Mike Allen Clock Kits, ¨
 ¨
"\t" will spit out the time. By the way, with only DateStamper by ¨
 ¨
itself there's no way to do this. ¨


BGii has a built-in print spooler with its resident SPOOL and Q ¨
 ¨
commands. I haven't needed to use them as I have a hardware ¨
 ¨
buffer but for those without a buffer these are indispensable. ¨
 ¨
Printer output from any number of text files is redirected into a ¨
 ¨
spool file which can later be printed while you simultaneously ¨
 ¨
work on something entirely unrelated. ¨


For those running Z-System on a Mini-Winnie hard disk I would say ¨
 ¨
BGii is worth the cost if only for a single reason: its key ¨
 ¨
redefinition capability. It has full-featured key defining at no ¨
 ¨
extra use of TPA. It even has a feature not found in other key ¨
 ¨
redefiners I've worked with, the ability to "attach" a set of ¨
 ¨
definitions that are automatically loaded along with a specified ¨
 ¨
application program. Since the above configuration tends to be ¨
 ¨
scrimpy on TPA as far as being able to load the standard Morrow ¨
 ¨
programs such as Smartkey or XtraKey that many of us have, the ¨
 ¨
cost that we might spend on a new, less TPA-intensive program is ¨
 ¨
better saved by spending a bit extra and getting BGii with its ¨
 ¨
task-switching and print spooling thrown in for just a bit more! ¨


I must address the always-critical issue of TPA here. I have a ¨
 ¨
program called TPA.COM written by the esteemed Bruce Morgen of ¨
 ¨
the Z-System SIG, that has been indispensable in my testing of ¨
 ¨
various configurations. I have DateStamper loaded in the only ¨
 ¨
place it can properly run while BGii is active as well, in the ¨
 ¨
location formerly taken up by the ZCPR3 IOP at EB80. This means ¨
 ¨
no IOP while running BGii. Of the three Input/Output packages ¨
 ¨
that can run here however, BGii duplicates the functions of two - ¨
 ¨
-NUKEY (key redefinition) and BPRINT (print spooling). I do, ¨
 ¨
however, miss having the capability of the third, RECORDER, which ¨
 ¨
provides a function that BG does not have, that of recording ¨
 ¨
console display to a disk file. The public domain program I/O-CAP ¨
 ¨
is a good substitute here for low-TPA projects. ¨


BGii uses 4.75k of memory, 2k of which replaces the standard ¨
 ¨
command processor. The user's manual says that when run on ZCPR3 ¨
 ¨
systems this is reduced to 2.25k by loading part of it, as I do, ¨
 ¨
into buffers whose functions are duplicated by BGii. ¨


I have no independent confirmation of the TPA sizes I am about to ¨
 ¨
provide here other than TPA.COM, so I cannot vouch for their ¨
 ¨
precise accuracy. Furthermore, bear in mind that in my system 2k ¨
 ¨
is eaten up by my hard disk driver. With DateStamper loaded at ¨
 ¨
EB80h but no BGii I have exactly 50.25k. With DateStamper loaded ¨
 ¨
at EB80h, and BG running, I have 47.5k TPA remaining for ¨
 ¨
programs, a difference of 2.75k, just a tad more than mentioned ¨
 ¨
in the BG documentation. This is adequate for virtually all of my ¨
 ¨
applications. The only work I can not do in this environment is ¨
 ¨
when I am experimenting with the large Turbo Modula-2 programs I ¨
 ¨
am writing with a series of public domain windows and graphics ¨
 ¨
routines. MexPlus, a much larger memory hog than its public ¨
 ¨
domain counterpart, runs fine and is able to load a 12k script ¨
 ¨
file on top of itself. NewWord, dBASE II, ZCPR3's ZEX all work ¨
 ¨
fine. My guess is that when WordStar 4.0 comes out I will not be ¨
 ¨
able to run BGii and simultaneously take advantage of WS's ¨
 ¨
calculator and block math functions, which require 50k. (By the ¨
 ¨
way, MicroPro has been trying to get the word out that their ¨
 ¨
earlier figure of 54k is not correct; 50k will suffice.)  I will ¨
 ¨
simply turn BG off when I want to use these functions of WS40. BG ¨
 ¨
can be turned on and off easily and quickly with the LOADBG and ¨
 ¨
BG OFF commands. ¨


Of BGii's two major features, task-switching is only feasible on ¨
 ¨
hard or ram disk systems. When the swap command is given, it ¨
 ¨
takes some time for the screen/memory image to be written to the ¨
 ¨
100k swap file. On my Mini-Winnie hard disk system it takes 8-10 ¨
 ¨
seconds to swap from one application to another. In the BGii ¨
 ¨
documentation it mentions that average swap time on a Kaypro 10 ¨
 ¨
hard disk with TurboROM is 4 secs. I was puzzled and a bit ¨
 ¨
disappointed in this and spoke with the author Bridger Mitchell ¨
 ¨
about it. He mentioned that the swap time is heavily dependent on ¨
 ¨
the quality of the BIOS and the TurboROM addition to the Kaypro ¨
 ¨
BIOS was specifically designed to "optimize" and streamline it. ¨
 ¨
He has suggested that the Morrow BIOS may be one of those guilty ¨
 ¨
of "buffer thrashing."  My knowledge of this subject is quite ¨
 ¨
limited, but Bridger's description of some specific behaviors of ¨
 ¨
some BIOSes that would definitely slow the swap time down is ¨
 ¨
confirmed as an adequate representation of the Morrow BIOS by our ¨
 ¨
resident BAMDUA BIOS expert in the San Francisco area. Since I ¨
 ¨
don't quite understand it, I think the best thing for me to do is ¨
 ¨
quote Bridger: ¨


.RR    L--!----!----!----!----!----!----!----!----!----!R
              The BGii swap algorithm is, roughly: copy ¨
 ¨
       TPA "sector" to buffer; read 1 sector to TPA; ¨
 ¨
       write buffer to same disk sector; increment sector ¨
 ¨
       number; repeat. ¨


              If the physical sector is greater than 128 ¨
 ¨
       bytes (most are now, e.g. all double density, all ¨
 ¨
       hard disks), then [an optimized] BIOS will ¨
 ¨
       recognize that the second sector (i.e. the next ¨
 ¨
       128 bytes) is still in the same PHYSICAL sector. ¨
 ¨
       It will neither read nor write the disk for that ¨
 ¨
       information, but rather just its "host buffer," ¨
 ¨
       which is one physical sector large. This continues ¨
 ¨
       until the physical sector is exhausted, and then a ¨
 ¨
       write/read is needed. But -- some BIOS's (Big ¨
 ¨
       Board I is one) read and write EVERY time; the ¨
 ¨
       technical term is "buffer thrashing." ¨


.RR--!----!----!----!----!----!----!----!----!----!----!--------R
This scenario sounds plausible to me, especially as I have a ¨
 ¨
report that swap time on an MD3 with a SWP Co-Processor RAMdisk ¨
 ¨
is 3.5 seconds which can be compared with 2 seconds on a Kaypro ¨
 ¨
with an Advent Products RAMdisk or 1 second on a 6MHz SB180. In ¨
 ¨
conversation with the aforementioned BIOS expert I am given to ¨
 ¨
understand that the difference in the ways various BIOSes do ¨
 ¨
their disk reads and writes is simply a difference in computer ¨
 ¨
philosophy; one way can be a asset in some situations and a ¨
 ¨
disadvantage in others. While I do find the 10 seconds on the ¨
 ¨
slow side, it generally does not get in the way of my overall ¨
 ¨
enjoyment of the program. ¨


From what I have been able to determine, Backgrounder is ¨
 ¨
unfortunately incompatible with the WestWind Drive C2: RAMdisk. ¨
 ¨
The two programs simply are competing for the same memory space ¨
 ¨
and most importantly each wants the other to be loaded first. The ¨
 ¨
SWP RAMdisk seems to be a little more flexible in this regard. I ¨
 ¨
am not 100% sure about the situation with the WestWind software ¨
 ¨
and had only a friend's Drive C2: and some limited technical ¨
 ¨
help; I would encourage anyone with this RAMdisk to call WestWind ¨
 ¨
and speak with the technical support staff about it. ¨


How feasible is it to run BGii on Morrow floppy disk machines? As ¨
 ¨
I mentioned previously having access to the 37 resident commands ¨
 ¨
is very valuable in itself even without task-switching. MD2 and ¨
 ¨
MD3 users would gain a considerable advantage over what they have ¨
 ¨
now in terms of number of resident commands, key redefinition, ¨
 ¨
print spooling and several other features. To be more precise I ¨
 ¨
should explain more completely that BGii is a command processor. ¨
 ¨
It is a command processor in the same manner that the CP/M CCP ¨
 ¨
is, or ZCPR3. As a matter of fact, BGii [BEGIN UNDERLINING]is[END ¨
 ¨
UNDERLINING] a ZCPR3-based command processor. BGii IS ZCPR3, or ¨
 ¨
more accurately it is actually ZCPR33!  Jay Sage, the author of ¨
 ¨
ZCPR33, collaborated very heavily in the final writing of BGii ¨
 ¨
and included most of its features in it. In other words, when you ¨
 ¨
are running Backgrounder you are running ZCPR33 without having to ¨
 ¨
install or purchase it separately. So without the task-switching ¨
 ¨
it still has quite a bit to offer floppy disk users. ¨

 ¨

Now for one caveat: BGii will not work under CP/M 3.0. It just ¨
 ¨
won't and that's that; there's no way around it. That eliminates ¨
 ¨
all the Morrow built-in hard disk machines from the picture. It's ¨
 ¨
most unfortunate that Digital Research abandoned support of CP/M ¨
 ¨
3.0 so early in the game. The irony of seeing all the good ¨
 ¨
enhancements coming out to support only the older CP/M 2.2 has ¨
 ¨
not escaped many of us. ¨


BGii has four or five advanced resident commands that depend ¨
 ¨
heavily on its ability to communicate with one's terminal ¨
 ¨
hardware. They are very exciting to use and I will describe them ¨
 ¨
below. They require the installation of something called a screen ¨
 ¨
driver. A screen driver is a piece of software that allows BGii ¨
 ¨
to interface completely and exactly with one's terminal hardware ¨
 ¨
and software functions. I ran BGii for about a month before I ¨
 ¨
realized I could use one of the already-existing screen drivers. ¨
 ¨
After loading the driver it increased my enjoyment of the program ¨
 ¨
tremendously. These screen functions are one of those things that ¨
 ¨
you don't miss when they're not there because you don't expect ¨
 ¨
them, but when you see them in action -- WOW!!!  Absolutely ¨
 ¨
incredible. ¨

For instance, I never thought I'd see the day that I did a full ¨
 ¨
CUT and PASTE from one program to another on my little vintage ¨
 ¨
1984 Morrow computer. When you see it it's quite beautiful. It ¨
 ¨
works the way you'd expect it to:  you highlight the text to be ¨
 ¨
CUT with your cursor keys and hit ^X to exit. Then go to your ¨
 ¨
second task and position the cursor where you wish your CUT text ¨
 ¨
to appear. Press <SUSPEND>, and when you are returned to the ¨
 ¨
prompt type PASTE. Now sit back and watch while BGii magically ¨
 ¨
inserts your text in your second program. After years of being ¨
 ¨
told CP/M machines have no video capabilities to speak of I must ¨
 ¨
admit I have allowed myself a certain healthy dose of good old- ¨
 ¨
fashioned self-righteousness. ¨


The counterpart to all this cutting and pasting is the SCREEN ¨
 ¨
command, which sends the exact image of what is on the screen to ¨
 ¨
the printer. This has been a joy to use. It has come especially ¨
 ¨
handy when I am logged on to bulletin boards and there is no easy ¨
 ¨
way to repeat the message I have just read. I just send it to the ¨
 ¨
printer and I'm on my merry way. ¨


The FLIP command is quite extraordinary; this allows you to ¨
 ¨
"flip" back and forth between one running task and the ¨
 ¨
screen/memory image of the second. You cannot actually WORK IN ¨
 ¨
the second task but only view it; it is not saved to the swap ¨
 ¨
file. Consequently the flips are instantaneous. Switching lightly ¨
 ¨
and quickly from one task to the other in a repeated manner is ¨
 ¨
truly a sight to behold and a most pleasant experience. ¨


Last but certainly not least in this pantheon of CP/M memory- ¨
 ¨
resident video adventures is the JOT command, and it is perhaps ¨
 ¨
this that I use most. In a way I suppose JOT takes me full circle ¨
 ¨
to where I began when I originally felt the need for BGii. This ¨
 ¨
command does exactly what it says: it allows you to write to a ¨
 ¨
JOTPAD while in the midst of any other program. It is similar to ¨
 ¨
the same function in programs such as Write Hand Man et al., but ¨
 ¨
at a much lower TPA penalty. The principle difference between ¨
 ¨
this and using the SWAP command to switch to a memory-based ¨
 ¨
editor such as VDE to jot down a quick thought is that no task- ¨
 ¨
switching is involved; we're not actually swapping to another ¨
 ¨
program but simply using a memory-resident command to write into ¨
 ¨
a file. Hence, again, it's practically instantaneous. ¨


These four advanced commands will not run without a screen ¨
 ¨
driver. A terminal's most crucial component for BGii's purposes ¨
 ¨
is the ability to send an image of itself to the host computer, ¨
 ¨
have the computer store it while the terminal is otherwise ¨
 ¨
occupied (with another task) and then send it back when ¨
 ¨
requested. My Qume 102a does it beautifully, and I have been able ¨
 ¨
to use the Televideo 950 driver released by Plu*Perfect. Those ¨
 ¨
with Wyse terminals also have screen drivers already written for ¨
 ¨
them. ¨


I believe the ADM20 terminal, especially those with the upgrade ¨
 ¨
kit installed, would be able to support these extra screen ¨
 ¨
features and a screen driver could be written for it. That job ¨
 ¨
remains to be done; there is sample source code available. ¨


I was not able to fully test the standard Morrow MDT60 and MDT70 ¨
 ¨
terminals, which are inferior to the ADM20, Qume, Televideo 950 ¨
 ¨
and Wyse in this regard, for support of BGii's advanced screen ¨
 ¨
functions. I tried loading the same Televideo screen driver I use ¨
 ¨
with my Qume on an MDT60 with poor results; the JOT, CUT and ¨
 ¨
PASTE, etc. commands definitely did not work. It was then ¨
 ¨
suggested to me, however, that plugged into the computer's [BEGIN ¨
 ¨
UNDERLINING]modem port[END UNDERLINING] a MDT60 or 70 might very ¨
 ¨
well work with the Televideo screen driver. I was unable to test ¨
 ¨
this. ¨


There is an easy solution for these concerns, however; anyone ¨
 ¨
interested in experimenting in this regard may simply obtain the ¨
 ¨
free, public domain demonstration version of Backgrounder. It is ¨
 ¨
available from MOR on a FLOB. It works exactly like the full ¨
 ¨
version but will not allow you to access any drive other than A:. ¨
 ¨
I would be most interested in hearing from anyone experimenting ¨
 ¨
with these video functions on any of the Morrow terminals. ¨


If you have a floppy-based Morrow then with an advanced terminal ¨
 ¨
such as a Qume or Wyse or any of the others that have the ability ¨
 ¨
to save a screen image and cursor positioning, I would ¨
 ¨
unhesitatingly recommend your purchase of BGii and that you ¨
 ¨
simply do not use the task-switching component. Not only will you ¨
 ¨
be running a full ZCPR33 system but these video and screen ¨
 ¨
commands will bring you many hours of delight. ¨


As a final caveat it must be mentioned that use of one's function ¨
 ¨
keys becomes problematic. There exist function key drivers that ¨
 ¨
work with keyboards whose function keys can send out characters ¨
 ¨
above 7Fh. The Televideo 950 can do this, along with a number of ¨
 ¨
other keyboards; mine can't and I don't believe the MDT series ¨
 ¨
can. Other than that, as far as I know one is left with one's ¨
 ¨
terminal hardware. My Qume, for instance, can be programmed in ¨
 ¨
hardware to send out 8 characters per function key. Since BGii ¨
 ¨
provides extensive key redefinition for the rest of the keyboard ¨
 ¨
one scarcely misses having full function key redefinition. I ¨
 ¨
don't know how the Morrow KEY.COM program would work; I simply ¨
 ¨
have been unable to test it. ¨


It should be pointed out, especially with the issue of screen ¨
 ¨
drivers, that BGii does all it can with the extraordinary ¨
 ¨
plethora of CP/M hardware presented to it. If some terminals such ¨
 ¨
as the MDT60/70 series are lacking in certain functions that ¨
 ¨
others have that BGii requires for its advanced features, I think ¨
 ¨
it is only fair to acknowledge a situation of a great difference ¨
 ¨
in grades and sophistication of hardware. My Qume 102a can do ¨
 ¨
gorgeous windows and graphics with the Modula-2 package I ¨
 ¨
mentioned previously; the MDT series can do nothing at all with ¨
 ¨
it. They just do not have the same kind of screen-save-and- ¨
 ¨
restore-cursor feature that is necessary. ¨


One recently released feature of BGii bears some explanation. An ¨
 ¨
Overlay Command Processor is an absolute miracle of programming ¨
 ¨
and I could scarcely believe it when I first came to understand ¨
 ¨
the concept. A series of OCP's began coming out a few weeks after ¨
 ¨
I first began using BGii. I had a full complement of resident ¨
 ¨
commands already and was amazed that so much could be packed into ¨
 ¨
2.75k of memory. Then various OCP versions started coming out on ¨
 ¨
the BBS circuit that now provided command line recall and editing ¨
 ¨
(BGHIST), an error handler (BGERRH), a resident copy command that ¨
 ¨
supports date-stamping, and an echo command with extra code in it ¨
 ¨
to display lower case letters --- all at no loss of TPA!  Bruce ¨
 ¨
Morgen of ZSIG explained: ¨


.RR    L--!----!----!----!----!----!----!----!----!----!R
       An Overlay Command Processor is a command package ¨
 ¨
       similar in form to the familiar ZCPR3 Resident ¨
 ¨
       Command Package. It can be as long as 4k and runs ¨
 ¨
       in the middle of the TPA, at 4000h. It takes up no ¨
 ¨
       TPA because it is loaded by the BGii command ¨
 ¨
       processor (from the swap file) only when needed. ¨
 ¨
       Just before loading the OCP and running the ¨
 ¨
       appropriate routine, BGii saves the 4k of memory ¨
 ¨
       starting at 4000h to the swap file, restoring it ¨
 ¨
       as needed when the OCP code is not running. Pretty ¨
 ¨
       simple, eh?  Such is the simple stuff of genius... ¨


.RR--!----!----!----!----!----!----!----!----!----!----!--------R

I should emphasize, by the way, that BGii is by no means ¨
 ¨
something that is meant to run only on ZCPR3 systems. It runs on ¨
 ¨
any CP/M 2.2 system, but will definitely turn your system into ¨
 ¨
ZCPR33. ¨


BGii's swap feature is not true "multi-tasking." Its print ¨
 ¨
spooling/queueing function is, however; two programs are ¨
 ¨
executing simultaneously. We've all been hearing so much about ¨
 ¨
multi-tasking from the MS-DOS world with their 80386 ¨
 ¨
microprocessor and its operating system for which everyone is ¨
 ¨
waiting (and waiting, and waiting...) that not enough people have ¨
 ¨
stopped to realize that they don't really need such a feature. ¨
 ¨
For a very large number of people, especially the writers among ¨
 ¨
us, BGii's extraordinary ability to temporarily allow you to ¨
 ¨
leave your word processor and the text you're working on and ¨
 ¨
enter any other program from which you might need some important ¨
 ¨
information, and then gracefully return, is just enough of what ¨
 ¨
we need. ¨


All in all I am very pleased with this program and its great ¨
 ¨
number of features. It does give one the feeling of having a ¨
 ¨
large new world opened up; one that seemed previously to exist ¨
 ¨
only in the IBM-compatible world. Jay Sage, author of ZCPR33 and ¨
 ¨
Director of the Boston Computer Society's CP/M Computers Group, ¨
 ¨
writes that BGii is "the most impressive and exciting piece of ¨
 ¨
software ever introduced for CP/M (Z80-compatible) computers."  I ¨
 ¨
have seen similar sentiments expressed many times elsewhere. The ¨
 ¨
first time you see a full task-swapping happen on your machine is ¨
 ¨
a very special and quite exhilarating feeling. On the Mini-Winnie ¨
 ¨
or the SWP RAMdisk it is ideal. For floppy disk owners wanting to ¨
 ¨
get a taste of what it's like to have extra resident commands ¨
 ¨
available without leaving a loaded program -- especially those ¨
 ¨
users with the more sophisticated terminals -- or even those ¨
 ¨
simply wanting to see what ZCPR33 is all about but unsure if they ¨
 ¨
are ready to buy the Morrow Z-System disk, I would encourage you ¨
 ¨
to try the free demonstration disk. ¨


     BGii's main author Bridger Mitchell is an active and ¨
 ¨
generous participant in the 8-bit user community. I have seen his ¨
 ¨
courtesy and friendliness in helping people with questions about ¨
 ¨
his products, providing support to an extent far greater than ¨
 ¨
that of many other software companies I have had contact with. ¨
 ¨
This is an excellent product, brilliant in its originality and ¨
 ¨
design, and one that makes a very important addition to our ¨
 ¨
still-expanding repertoire of 8-bit, CP/M-compatible software. ¨



BACKGROUNDER II, $75 from Plu*Perfect Systems, P.O. Box 1494, ¨
 ¨
Idyllwild, CA 92349. ¨

